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Background of the Invention 
Field of the Invention 

[0001 ] The present invention is related to creditworthiness data collec- 
tion and aggregation, and more particularly to collecting payment history data 
from a large number of users by uploading data directly from installed financial 
or accounting software applications, aggregating such data at a central location, 
and generating reports and/ or alerts based on the aggregated data. 

Description of the Background Art 

[0002] Assessments of creditworthiness are valuable in many business- 
related situations. Businesses often extend credit to other firms and/ or indi- 
viduals, for example by selling goods or services and billing the purchaser via an 
invoice for later payment. Creditors, such as vendors of products or services, 
wish to avoid extending credit to individuals and business entities that are likely 
to default on their obligations. Accordingly, most creditors perform some form 



Case 5393 



-1- 



16319/05393/DOCS/1127126.3 



of " credit check" on a potential debtor (e.g., a customer) before extending credit. 
Such credit checks are also performed in other situations where it is desirable to 
investigate the overall trustworthiness and/ or ability to pay of an individual or 
business entity (referred to herein as a " subject company"). 

[0003] Conventionally, a creditor performs a credit check by consulting 
a trusted provider (if credit information, such as Dun & Bradstreet. At the credi- 
tor's request, the provider generates a credit report or other document that 
summarizes the credit history of a subject company. Based on the credit report, 
the creditor evaluates the creditworthiness of the subject company, and thereby 
makes business decisions as to whether and to what extent to extend credit to the 
subject company. 

[0004] Credit reports generated by providers such as Dun & Bradstreet 
are typically based on large amounts of creditworthiness data that have been col- 
lected over a period of time. Such creditworthiness data may be based, for ex- 
ample, on publicly available records such as bankruptcy filings, liens, judgments 
and the like, summaries of the type of business and length of time the business 
has been in operation, complaints or comments from other vendors, and the like. 
In general, the creditworthiness data that is used by credit information providers 
is only as reliable as the techniques employed for collecting the data. To the ex- 
tent that such data is collected indirectly or that the data collection relies on the 
efforts of individuals to accurately report their observations and interactions, the 
data is subject to inaccuracies. In addition, to the extent that such data is un- 
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available, such as for small companies or those that have not been in business a 
long time, the creditworthiness report may not be accurate or may not be avail- 
able. Also, credit reports from providers such as Dun & Bradstreet typically at- 
tempt to cover payment behavior of businesses and fail to cover that of consum- 
ers. 

[0005] Payment history is a particularly good indicator of creditwor- 
thiness, and many creditors rely on a subject company's payment history, as re- 
ported by others, in determining whether to extend credit to the company. Ac- 
cordingly, credit information providers regularly obtain payment history data 
from vendors and other creditors, as part of their creditworthiness data collection 
efforts. 

[0006] Conventionally, due to practical limitations, it is not feasible to 
collect data for every payment, or even for a large subset of payments, made by a 
particular subject company. Therefore, credit information providers typically 
collect payment history data from a subset of vendors who have dealt with the 
subject company. These vendors themselves do not typically report transaction- 
level payment data, but rather provide aggregated information about the subject 
company's payment patterns (e.g., number of times 30 days late). Such data is 
then further aggregated and extrapolated by the credit information provider in 
order to develop an assessment of the subject company's overall payment per- 
formance. Since the experiences of the vendor subset may not be representative 
of the overall behavior of the individual or company, and since in many cases the 
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total quantity of available data for a subject company may be limited, the resul- 
tant report may suffer from inaccuracies. 

[0007] What is needed, then, is a technique for expanding the scope of 
data collection for credit history data, so as to improve the accuracy and reliabil- 
ity of resultant creditworthiness reports. 

[0008] What is further needed is a technique for collecting payment 
history data in an automated fashion, directly from vendors or other business en- 
tities, and without introducing subjective assessments of payment history, so as 
to further improve the accuracy and reliability of creditworthiness reports. 

Summary of the Invention 

[0009] The present invention collects payment history data from a 
large number of users, such as vendors, by uploading data from stored files of 
financial or accounting software packages. In one embodiment the users are un- 
affiliated with one another; they are, for example, separate individuals and/ or 
businesses that do not normally share transaction data with one another. Col- 
lected data is then aggregated at a central location in order to generate credit his- 
tory reports and creditworthiness assessment reports and alerts for various sub- 
ject companies whose payment transactions or patterns are reflected in the col- 
lected data. 

[001 0] In one aspect of the invention, financial or accounting software 
packages running on users 7 computers periodically upload accounts receivable 
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data to a central server. The uploading may be performed over a network such 
as the Internet. Data is uploaded automatically, and in one embodiment is per- 
formed in an anonymous manner that protects the confidential information of 
the user. The uploaded information for each subject company is then aggre- 
gated, and a determination of each subject company's creditworthiness is made. 
The creditworthiness information, along with underlying transactional or sum- 
mary information, may be provided to the users or to others in the form of credit 
reports. 

[001 1 ] In one embodiment, the invention may seek to obtain the user's 
consent prior to commencing uploads. In exchange for providing such consent, 
the invention may allow the user to access credit reports on subject companies 
for free or for a discounted fee. 

[0012] Uploaded accounts receivable data may include, for example, 
billing and payment dates for subject companies, aging histories, and other data 
that is typically available to users of financial or accounting software packages, 
or that is generated by such packages in the form of reports and charts. 

[0013] In another aspect of the invention, credit reports on subject 
companies are made available to users of the financial or accounting software 
packages. Such credit reports may be based on the collected and aggregated 
creditworthiness data, and may be provided to users via the Internet. For exam- 
ple, a report may be made available to a user via a web page or within the con- 
text of the financial or accounting software package. The report may be custom- 
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ized to the user's needs, for example by presenting data for those subject compa- 
nies that are of particular relevance to the user. Reports may be made available 
for a fee, and appropriate discounts or complimentary reports may be made 
available for those users that allow their accounting data to be collected. 

[001 4] Credit reports generated by the present invention may be pre- 
sented in any desired format, including formats that are known in the art for pre- 
senting creditworthiness data. In addition, creditworthiness data may be pre- 
sented to users of financial or accounting software in a manner that integrates 
presentation of the data with other functionality of the software. For example, 
when the user enters a transaction containing the name of a particular company, 
the software may present an indicator of the relative creditworthiness rating of 
the company. An icon representing the rating may be displayed on the transac- 
tion screen, and the user may be given the opportunity to click on the icon to ob- 
tain a more detailed report. In addition, the system of the present invention may 
automatically notify users when a rating for a company changes, particularly if 
the user does business with the company, has previously requested a report for 
the company, or has otherwise indicated an interest in the credit rating of the 
company; such notifications may be provided as an alert box within a software 
application, or via e-mail or website, or by other means. Thus, the present inven- 
tion allows credit reports to be customized to particular users, by presenting 
them with information relevant to the particular companies with whom they do 
business. 
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[001 5] The present invention thus avoids the limitations discussed 
above with respect to prior art schemes for collecting and aggregating creditwor- 
thiness data. In particular, payment history and other creditworthiness data are 
collected in a more widespread fashion, more reliably, and with a minimum of 
user effort. Aggregated creditworthiness data collected at a central server may 
be updated in real time, as payment history data is received from users. 

[0016] By interfacing with a widely distributed financial/ accounting 
software application, such as QuickBooks® by Intuit® Inc., the present invention 
takes advantage of a very large installed base of users. Collecting data from such 
a large number of users allows the present invention to be able to generate ex- 
tremely accurate creditworthiness reports, even for smaller companies and for 
consumers. 

[001 7] The features and advantages described in this summary and the 
following detailed description are not all-inclusive, and particularly, many addi- 
tional features and advantages will be apparent to one of ordinary skill in the art 
in view of the drawings, specification, and claims hereof. Moreover, it should be 
noted that the language used in the specification has been principally selected for 
readability and instructional purposes, and may not have been selected to de- 
lineate or circumscribe the inventive subject matter, resort to the claims being 
necessary to determine such inventive subject matter. 
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Brief Description of the Drawings 

[001 8] Fig. 1 is a block diagram depicting an overall architecture for an 
embodiment of the present invention. 

[001 9] Fig. 2 is an interaction diagram of a method for practicing the 
present invention. 

[0020] Fig. 3 is an example of a screen shot displaying a creditworthi- 
ness rating in the context of a transaction register. 

[0021 ] Fig. 4a is an interaction diagram depicting user registration 
according to one embodiment of the present invention. 

[0022] Fig. 4b is an interaction diagram depicting payment data trans- 
fer according to one embodiment of the present invention. 

[0023] Fig. 4c is an interaction diagram depicting user subscription 
according to one embodiment of the present invention. 

[0024] Fig. 4d is an interaction diagram depicting credit information 
transfer according to one embodiment of the present invention. 

[0025] The figures depict a preferred embodiment of the present inven- 
tion for purposes of illustration only. One skilled in the art will readily recognize 
from the following discussion that alternative embodiments of the structures and 
methods illustrated herein may be employed without departing from the princi- 
ples of the invention described herein. 
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Detailed Description of the Preferred Embodiments 

[0026] For illustrative purposes, the preferred embodiment of the pre- 
sent invention is described in the context of collection of creditworthiness data, 
over the Internet, from an installed base of users of an accounting software pack- 
age. Those skilled in the art will recognize that the particular features of the pre- 
sent invention are not limited to a particular environment, software application, 
or network configuration, and that the following description is merely intended 
to be illustrative of one embodiment. The scope of the invention is therefore not 
intended to be limited by the particular implementation described below, but 
rather defined solely by the claims. 

[0027] Referring now to Fig. 1, there is shown a block diagram depict- 
ing an overall architecture for an embodiment of the present invention. Refer- 
ring also to Fig. 2, there is shown an interaction diagram of an overall method for 
practicing the present invention according to one embodiment. In one embodi- 
ment, the invention operates in conjunction with a number of clients 104. Each 
client 104 may be a conventional desktop computer, including a central process- 
ing unit (CPU), display, disk drive, modem, and input devices. One skilled in 
the art will recognize that laptops, handheld computers, personal digital assis- 
tants (PDAs), Internet appliances, and other computing devices may also be cli- 
ents 104. Each client 104 executes a software application such as an accounting 
software package, financial software package, accounts receivable software pack- 
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package, or the like. The various clients 104 need not be running the application 
simultaneously, as data can be collected in an asynchronous manner whenever 
each client 104 happens to activate the software or open an active connection 
over which data can be transferred. Each client 104 stores local data 105 relevant 
to the software application in a conventional manner. Alternatively, for web- 
based software applications or Application Service Provider ( ASP)-based imple- 
mentations of accounting and financial software, such data may be stored at a 
remote server, with access to the data being restricted to authorized persons. All 
clients 104 may use the same software package, or they may use different soft- 
ware packages from one another; where different software packages are used by 
various clients 104, the software packages may be from the same manufacturer or 
from different manufacturers. Clients 104 are connected to the Internet 103 or 
some other centralized network via conventional means (e.g. telephone modem, 
direct subscriber line (DSL), cable modem, and the like). 

[0028] In one embodiment, at least a subset of the users are unaffiliated 
with one another; they are, for example, separate individuals and/ or businesses 
that do not normally share transaction data with one another. Rather than 
merely collecting transaction data from a number of users (such as employees) 
affiliated with a single business entity, the present invention collects data from 
any number of users that may not work together or be otherwise associated with 
one another. The present invention thereby utilizes a wider cross-section of 
transaction data, and facilitates generation of more accurate creditworthiness 
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data than would normally be obtainable from transaction data of one business 
entity alone. 

[0029] In one embodiment, data collection takes place whenever a user 
connects to the Internet 103, whether or not the software is active at the time of 
connection. Such data collection may thus take place via a background transfer. 
For example, in one embodiment a background process (not shown) is initiated 
upon operating system startup. The background process continues to operate 
while the user is engaged in other tasks on the computer. The background proc- 
ess continually monitors the status of the client's network connection to deter- 
mine a suitable time at which transaction data should be collected. Various pa- 
rameters may be set for such determination, so that, for example, the data collec- 
tion does not unduly affect the bandwidth available for other tasks. In general, 
the background process initiates data collection when it determines that a net- 
work connection is available and that sufficient bandwidth is available without 
interfering with other tasks. Once such a determination is made, the background 
process initiates a connection to centralized server(s) 101 over the Internet 103. 
The background process identifies the client machine 104 it is running on, and 
interacts with server(s) 101 to perform appropriate authentication and handshak- 
ing to establish and verify the connection. The background process then trans- 
mits transaction data to server(s) 101 over the Internet 303. In one embodiment, 
the transmission takes place in a secure manner using encryption technology 
and/ or other security and authentication techniques as are known in the art. If, 
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during the data transmission, the connection is lost or the available bandwidth is 
reduced to a level that does not permit transaction data to be transmitted without 
unduly affecting other operations, the data transmission is halted. It may then be 
resumed at a late time, when the connection is available and the conditions for 
data transfer are more suitable. 

[0030] In another embodiment, a connection to the Internet may be ini- 
tiated automatically on a periodic basis so that data can be collected. In yet an- 
other embodiment, data collection takes place in response to a user's explicit in- 
struction, or at periodic intervals during a user session. Where a continuous 
network connection is available, data collection may be performed as frequently 
as is practicable or desired. 

[0031] If desired, users may be made aware that data collection is tak- 
ing place, though such notification is not necessary to practice the present inven- 
tion. In one embodiment, users are given an opportunity to "opt in" 201, or con- 
sent to the collection of accounts receivable and/ or transaction data. Users may 
be asked whether they consent to data collection at the time they install the ac- 
counting or financial software. Alternatively, the software may prompt them at 
periodic intervals. In alternative embodiments, users are prompted for their 
permission at each instance of data collection. The software may show the user 
the data being collected, and may give the user the opportunity to approve 
and/ or annotate the data before it is transmitted. Showing users the data being 
collected may reassure the users that their personal privacy is not being violated. 
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In yet another embodiment, the software defaults to a mode in which data is col- 
lected, forcing users to "opt out" if they do not want the data to be collected. In 
yet another embodiment, the software does not provide users with such options, 
but collects data from users without requesting or requiring their consent. 

[0032] Various techniques may be employed for encouraging users of 
the software to allow their accounts receivable data to be transmitted to central 
server (s) 101. As described above, those users who consent to the transmission 
and use of their data may be provided with reports for free or for a reduced rate, 
and/ or may be provided with free or reduced-price software upgrades, access to 
improved features of the software, and the like. In addition, those users who 
consent might be given permission to affix a distinctive logo or message on their 
invoices to debtors, indicating that the sender of the invoice participates in such 
credit information collection; such a logo or message might encourage debtors to 
pay such an invoice more promptly, since they would be aware that their pay- 
ment history is being reported. 

[0033] Users enter transactions 202 in the software application using 
data entry screens that are common to conventional accounting or financial soft- 
ware applications. Typically, such data entry is performed over a period of time, 
as day-to-day transactions take place and are recorded. Transaction data in- 
cludes, for example: transaction date; invoice date; invoice number; company; 
description; amount; category; and the like. Transaction data is stored, for ex- 
ample, in local data storage 105 at clients 104, as is known in the art. Alterna- 
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tively, for web-based software applications or Application Service Provider 
(ASP)-based implementations of accounting and financial software, such data 
may be stored at a remote server, with access to the data being restricted to au- 
thorized persons. The techniques of the present invention are applicable to ei- 
ther type of architecture and storage scheme. 

[0034] In one embodiment, server(s) 101 are implemented using any 
combination of commonly-available web servers as are known in the art. 
Server(s) include several functional components, including, for example: 

[0035] - data collection module 101B, for collecting, from clients 104, 
data describing the payment history of subject companies; 

[0036] - data aggregation module 101 A, for aggregating the collected 
data concerning a particular subject company; 

[0037] - report generation module 101C, for generating reports describ- 
ing creditworthiness of subject companies; 

[0038] - alert generation module 101D, for generating alerts describing 
creditworthiness of subject companies; 

[0039] - report distribution module 101F, for distributing reports de- 
scribing creditworthiness of subject companies; 

[0040] - alert distribution module 101E, for distributing alerts describ- 
ing creditworthiness of subject companies; 
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[0041 ] - registration module 101G, for providing log-in functionality, 
verifying user identities, and tracking users' interactions with the functionality of 
the invention; and 

[0042] - business logic 101H, for controlling subscription and report ac- 
cess functions. 

[0043] In one embodiment, data collection module 101B of server(s) 
101 of the present invention collects data describing the payment history of com- 
panies with which the user has conducted business. This is accomplished by pe- 
riodically uploading 203 transaction data to server (s) 101. In one embodiment, 
individual transaction data (e.g., both invoice and payment data), as stored in 
local data 105, is collected. Alternatively, data for particular companies is aggre- 
gated at client 104 and transmitted to module 101B in an aggregated form; such 
aggregated data may include, for example, accounts receivable aging data. Par- 
ticulars of subject companies, such as their names, locations, or other identifying 
information, may also be collected, so as to adequately identify the companies to 
facilitate aggregation with data collected from other users. 

[0044] In one embodiment, the data is transmitted in a secure fashion 
over the Internet 103, using techniques and protocols that are known in the art 
for such data transfer. 

[0045] In one embodiment, data is uploaded 203 whenever such trans- 
fer is most convenient to the user, such as when a connection to the Internet 103 
is established, or when the software application is opened or closed, or when a 
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connection is available and bandwidth is sufficient. In other embodiments, data 
transmission may be user-initiated or server-initiated. 

[0046] The data uploaded in 203 may include transaction data itself, or 
it may include aggregated transaction data that describes payment behavior of 
those companies with whom the user does business; such aggregated data may 
be generated, for example, using report construction functionality within the 
software applications, such as that commonly used for accounts receivable re- 
ports. In one embodiment, data is uploaded in an anonymous manner that pro- 
tects the confidential information of the user. 

[0047] In one embodiment, once the user opts in 201, transactions that 
were previously entered (before opt-in) may be uploaded. Thus, the invention is 
able to "catch up" by collecting data for transactions that took place before opt- 
in. In one embodiment, the user is given an opportunity to permit or disallow 
such an operation. The catch-up upload may take place immediately following 
receipt of the user's opt-in, or at the same time as the first new transaction is up- 
loaded, or at any other convenient time. 

[0048] Those skilled in the art will recognize that many other schemes 
for initiating and scheduling the transmission and collection of the transaction 
data may be employed without departing from the present invention. In one 
embodiment, data is transmitted according to techniques and protocols that are 
known for transmission of data over a network connection. In an ASP-based im- 
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plementation, data is transmitted from the application's transaction storage de- 
vice (not shown) to server (s) 101. 

[0049] Data aggregation module 101 A within server(s) 101 aggregates 
204 uploaded data, and stores it in central data storage 102 along with data col- 
lected from other clients 104. In one embodiment, module 101 A aggregates data 
based on company names as entered by users of the software; thus all collected 
transaction data for a company named " Acme" would be aggregated by module 
101 A prior to storing the data in storage 102. In another embodiment, server(s) 
101 normalizes the company name information in the uploaded data in order to 
account for variations in the spellings, formats, and punctuations of entered 
company names. Server(s) 101 are thereby able to recognize transactions that re- 
fer to the same business entity even if the users entered the company name 
slightly differently. In normalizing for such variations, server(s) 101 may per- 
form various operations such as: 

[0050] - stripping out punctuation and common words such as "the" or 

"inc."; 

[0051 ] - matching variations in spelling; and 

[0052] - checking for similarity in address, telephone number, e-mail 
address, domain name, or other company information. 

[0053] For example, aggregation module 101 A would determine that 

"Office Depot," "The Office Depot," and "Office Depo" all refer to the same 
company, so that the credit information would be properly aggregated among 
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transactions using all three versions of the name. Other techniques for detecting 
matches despite variations in entered names are known in the art and may be 
applied as desired. In addition, in one embodiment the invention avoids errone- 
ously combining data for similarly named entities by checking for matches in 
addresses, telephone numbers, or other secondary information. Storage 102 may 
also contain a directory of subject companies, so that when a user enters a trans- 
action identifying a subject company, the directory may be consulted in order to 
obtain the likely matches to the subject company identified by the user. In yet 
another embodiment, when a user enters a company name in the course of re- 
cording a transaction, the user is presented with a list of likely matches and 
prompted to select one, so that the correct company is properly identified. If the 
user indicates that none of the listed companies is correct, a new record for the 
entered company may be created and stored. 

[0054] One skilled in the art will recognize that normalization of com- 
pany names is not necessary to practice the present invention, and that the inven- 
tion can be implemented without any functionality for detecting close matches 
among company names. 

[0055] Aggregated data is stored in central data storage 102. In one 
embodiment, aggregation 204 includes generating and indexing combined pay- 
ment history data on a company-by-company basis. Storage 102 may be imple- 
mented using known database applications and tools, such as an Oracle data- 
base. In one embodiment, storage 102 includes database records for each of a 
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plurality of companies for whom transaction data has been collected and aggre- 
gated. For each of these companies, an assessment of creditworthiness, such as 
for example a quantified creditworthiness rating, is derived. Creditworthiness 
ratings are determined from collected information using conventional techniques 
for assessing and quantifying relative credit risk based on payment history; such 
techniques are well known in the art. 

[0056] As module 101B of server(s) 101 collects additional data, the 
data is stored in storage 102 and the creditworthiness ratings for the subject 
companies are updated accordingly. In one embodiment, creditworthiness rat- 
ings are stored along with the aggregated data in storage 102; in another em- 
bodiment, creditworthiness ratings are not stored, but are derived from the ag- 
gregated data when needed or requested, in real time. 

[0057] Creditworthiness reports and/or alerts are then generated 205 
based on the aggregated transaction data. Such reports include, for example, 
creditworthiness assessments of selected companies. In one embodiment, report 
generation module 101C of server(s) 101 generates reports 106 using report gen- 
eration features of the database application used to store the aggregated data, as 
is known in the art. Similarly, alert generation module 101D generates alerts 107 
describing changes to creditworthiness assessments of subject companies, when 
such changes are relevant to particular users. Reports 106 and alerts 107 may be 
generated according to any or all of the following criteria, for example: 

[0058] - on demand, by end users or by system operators; 
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[0059] - periodically, according to predefined criteria; 

[0060] - upon occurrence of predetermined triggering events (e.g. a 
first detected transaction with a particular company); and 

[0061 ] - upon detection of a significant change in a company's 
creditworthiness rating. 

[0062] Report distribution module 101F then transmits 206A generated 
reports 106 to client 104 by whatever means are appropriate and desired, and cli- 
ent 104 displays 206B the reports to the user. Similarly, alert distribution module 
101E transmits 206A generated alerts 107 using alert generation features of the 
database application used to store the aggregated data, as is known in the art. 
Reports may be made available to selected users, or to the public at large, by 
publication on a web page, by hard copy printout, by e-mail, or by any other ap- 
propriate mechanism. Alternatively, reports may be made available to users in 
the context of the accounting or financial software application, via a reports 
command or menu within the application, or via a dialog box provided for re- 
questing creditworthiness data for a company. Business logic 101H may be em- 
ployed to control subscription and report access functions. 

[0063] In one embodiment, an indication of a company's creditworthi- 
ness rating, as determined based on aggregated data, may be displayed to a user 
whenever the user enters the company's name in the course of inputting a trans- 
action. Referring now to Fig. 3, there is shown sample screen 300 in which credit 
rating 304 for a company is displayed alongside other particulars for a transac- 
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tion 301. In sample screen 300, several transactions 301 (such as invoices) are 
displayed, each including a date 302, invoice number 307, company name 303, 
transaction amount 305, and balance 306. Credit rating 304 is displayed along- 
side the other transaction data, and may be displayed, for example, in response 
to the user's entry of a company name 303. In one embodiment, the user may 
click on credit rating 304 to view a more detailed credit report on the subject 
company. 

[0064] In one embodiment, credit rating 304 is obtained "on the fly" 
from server(s) 101 when a user enters a company name. Client 104 recognizes 
the entered company name and requests the relevant credit rating 304 from 
server(s) 101. Credit rating 304 may also be stored locally, once obtained from 
server(s) 101, so that if the user subsequently views the transaction screen client 
104 need not make a second request for credit rating 304. In another embodi- 
ment, credit ratings for a number of companies (for example, those companies 
with whom the user does business) may be periodically downloaded and stored 
locally, so that credit rating 304 can be displayed whenever the user enters a 
company name or reviews a transaction for a company, without requiring a new 
request to server(s) 101. Such downloaded information may be updated periodi- 
cally or in response to alerts from server(s) 101 that a rating has changed. 

[0065] The numeric rating shown in Fig. 3 is merely an example of one 
possible representation of a credit rating. Alternatively, an icon or color-coded 
indicator may be displayed, representing a relative degree of creditworthiness. 
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One skilled in the art will recognize that other types of indicators or representa- 
tions of credit ratings may be used. 

[0066] Registration module 101G provides functionality related to reg- 
istration, identification, and recognition of users. Module 101G provides a log-in 
screen that prompts users to enter an identifier and password, and further pro- 
vides the back-end functionality for authenticating user identity based on such 
entered information. Registration module 101G may also handle collection of 
payment information (such as credit card numbers) for use of the services associ- 
ated with the creditworthiness reporting functions, and may also prompt users 
to enter demographic or other information, for purposes such as tracking, adver- 
tisement targeting, and the like. In one embodiment, module 101G maintains a 
user database, either in central data storage 102 or in another storage device, for 
storing lists of registered users, and for tracking the activity of such users with 
respect to the creditworthiness reporting functionality of the present invention. 
For example, module 101G may track the types of reports a particular user re- 
quests, as well as the subject companies of the requested reports, so as to deter- 
mine what information is of greatest interest to the user. Report generation 
module 101C and alert generation module 101D can tailor subsequent reports 
and alerts in response to these interests. Methods and techniques for user regis- 
tration, login, and tracking are well known in the art. 

[0067] Business logic 101H, which may be configured by a system op- 
erator, specifies in one embodiment which reports should be made available to 
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which users. For example, in one embodiment, reports may be made available 
only to those users who have subscribed to a reporting service, or who have paid 
a fee, or who have agreed to allow the system to transmit their accounting data 
to server(s) 101. Users may elect to "subscribe" to reports for particular compa- 
nies, or reports may be automatically provided to users, based on lists of compa- 
nies with whom they regularly do business. Opt-in and/ or opt-out functionality 
may be provided. Subscription data may be stored centrally by server(s) 101 (in 
which case the appropriate reports are provided and transmitted to subscribed 
users), or alternatively it may be stored in local data 105 of individual clients 104 
(in which case client software makes the requests as to the particular companies 
to which the user has subscribed). Users can thus subscribe so that they receive 
updates as to future changes in creditworthiness data for a company, or they 
may specify single requests of a "one-shot" report on a company. Users are iden- 
tified and authenticated by registration module 101G, as described above. 

[0068] As described above, storage 102 may also contain a directory of 
subject companies. In one embodiment, storage 102 maintains an index that in- 
dicates, for each given user, which subject companies are of interest; conversely, 
the index may indicate, for each subject company, which users are interested in 
or do business with the company. Alert generation module 101D and report 
generation module 101C may then consult the indexes in storage 102, in order to 
determine who should receive particular reports and alerts, and in order to 
properly tailor such reports according to users' needs and according to the level 
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of service to which they have subscribed. In one embodiment, the parameters for 
such determination and tailoring are defined and implemented by business logic 
101H. 

[0069] In one embodiment, users may be offered a certain number of 
subscriptions and one-shot reports for free or for a specified fee, and premium 
services may also be offered, which allow access to more detailed reports or to a 
greater number of reports. Additional reports may be offered to collection agen- 
cies or other businesses that are interested in creditworthiness data for compa- 
nies; such reports may be tailored to the particular needs of the businesses. Vari- 
ous structures and business arrangements may be made, and implemented in 
business logic 101H, for providing access to reports 106 and alerts 107 in various 
ways. One skilled in the art will recognize that the methodologies described 
herein are merely exemplary. 

[0070] For example, a minimal level of information describing a subject 
company is the credit rating, which may be expressed as a grade (such as A++, 
A+, A, B, and the like), or as a numeric indicator (such as 8 out of 10), or by any 
other means. A first tier of reporting service might provide users with this rat- 
ing, but would not include any further details regarding the subject companies. 
A second tier might additionally provide summary information concerning sub- 
ject companies, such as for example the average days the subject company takes 
to pay an invoice, relative to some common set of terms, such as "Net 30" or the 
like. A third tier might provide a more detailed chart showing the average days 

Case 5393 - 24 - 

26319/05393/DOCS/1127126.3 



to pay for various invoice amounts or ranges of amounts. Such information 
might further include useful statistics, such as noting the maximum invoice 
amount the subject company normally encounters. 

[0071 ] Various subscription levels, or tiers, can be implemented by 
business logic 101H. For example: 

[0072] - basic tier: ten reports per month; 

[0073] - deluxe tier: 100 reports per month; or 

[0074] - premier tier: unlimited reports. 

[0075] Similar tiers may be established for alerts. Restrictions may be 
placed on access to reports on subject companies with whom the user has never 
transacted, if desired; alternatively, such restrictions may only be enforced on 
users that are subscribed to lower tiers of service. 

[0076] Reports and alerts may be made available for free for a limited 
time, if desired, as a promotional vehicle. 

[0077] In one embodiment, report distribution 101F may transmit 
alerts, such as by e-mail or by some other communication means, describing up- 
dated creditworthiness assessments. Such alerts may be transmitted to those cli- 
ents 104 that have previously conducted business with the subject company, or 
who have otherwise indicated an interest in the subject company (for example, 
by subscribing to reports for that company). In one embodiment, the alert identi- 
fies the subject company, includes a brief description of the change in the credit 
rating, and provides a hyperlink to a more detailed report as may be made avail- 
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able via a web page. Clicking on the link generates a request to server(s) 101 to 
prepare and transmit the appropriate report to client 104 as a web page. In this 
manner, a user is informed if there has been a significant change in creditworthi- 
ness assessment for a particular company with which the user does business, and 
the user is given an opportunity to access more detailed information regarding 
the change and the underlying historical data. 

[0078] In one embodiment, the selection of which reports and/or alerts 
to provide to which users may also be adjusted based on geographic considera- 
tions. For example, users known to be marketing their products or services in a 
particular geographic region and to a particular type of company may be pre- 
sented with creditworthiness reports and/ or alerts for companies within that re- 
gion and of that type. Geographic regions may be defined by any known tech- 
nique, such as ZIP code, city, state, and the like. Geographic data for a subject 
company may be extracted from a stored record (which would contain such in- 
formation as previously entered by the user), or such data may be retrieved from 
a directory or other data source. Geographic data for a particular user may be 
determined, for example, if the user is queried for such information by the client 
software application, e.g. at initialization or installation of the application. 

[0079] Creditworthiness data as collected and aggregated by the pre- 
sent invention may also be used in assessing the value of a company's receiv- 
ables for the purpose of factoring. Factoring is the sale of an account receivable. 
The factor pays cash for the receivable, exchanging one asset (cash) for another 
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asset (an account receivable). The creditor need no longer wait for receivables to 
be paid by the debtor. Typically the purchase price for the account receivable is 
discounted from the amount actually owed by the debtor. The creditworthiness 
data generated by the present invention may be used to determine the relative 
risk associated with the account receivable and thereby establish an appropriate 
purchase price. 

[0080] By collecting transaction data directly from an installed base of 
users of a financial or accounting software package, the present invention advan- 
tageously facilitates aggregation of large quantities of transaction history data, 
and thus enables generation and distribution of more accurate creditworthiness 
reports with a minimum of user effort and cost. The invention further facilitates 
distribution of such reports to those users who are most likely to be interested in 
the information contained therein, and provides the capability to tailor the re- 
ports to the needs of individual users. 

[0081] In one embodiment, the transaction data is collected in such a 
manner that the source of the data remains anonymous. Thus, companies whose 
creditworthiness rating is adversely affected by reported data are unable to track 
the source of the data. However, in an alternative embodiment, a mechanism 
may be put in place for allowing subject companies to determine the source of 
such transaction data, particularly in a situation where the adverse data is erro- 
neous. For example, the provider of the service may keep track of transaction 
data sources, and may divulge source information to subject companies only 
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when it appears that an error has been made. Other schemes may also be pro- 
vided; for example, source information may be provided to those companies that 
pay a higher fee, or it may be provided only when the source has indicated that it 
is willing to share such inf ormation, or according to any other desired criterion. 
Depending on the nature of the application, one skilled in the art will recognize 
that different schemes for providing and/ or protecting such information may be 
appropriate. 

[0082] Referring now to Figs. 4a through 4d, there are shown interac- 
tion diagrams depicting various operations that may be performed according to 
one embodiment of the present invention. The particular sequence of requests, 
responses, and other communications depicted in Figs. 4a through 4d are merely 
exemplary, and are not intended to limit the scope of the invention claimed 
herein. 

[0083] Fig. 4a depicts a user registration operation. Such an operation 
is performed, for example, when a new user signs on to the creditworthiness re- 
porting system, or when such a user initially agrees that his or her transaction 
information is to be collected by the system of the present invention. In such a 
situation, the user may be given the opportunity to select and provide a login 
identifier and a password, as well as other information. User registration may 
also take place when a returning user signs on with a pre-selected login identifier 
and password, and is thereby recognized by the system of the present invention. 



Case 5393 



-28- 



16319/05393/DOCS/1127126.3 



[0084] Client 104 transmits a user registration request 401 to server 101. 
Request 401 includes a user identifier (such as a log-in), and an authentication 
token (such as a password). Request 401 may also include an indication as to 
whether or not the user would like to "opt in" to the data collection performed 
by the system of the present invention. If this is the user's first interaction with 
the system, additional information, such as e-mail address, type of business, 
demographic information, and the like, may also be collected* The user may be 
prompted for such additional information at the time of request 401, or in a fol- 
low-up communication. 

[0085] According to the architecture described above, such a request 
401 would be handled by registration module 101G of server 101. If the user's 
identifier is recognized and the authentication token is verified, server 101 re- 
sponds 402 to request 401 with an indication of success. If a new user success- 
fully provides requested information, server 101 also responds 402 with an indi- 
cation of success. If the user's identifier is not recognized, or if the authentication 
token is not verified, or if requested information is not provided, server 101 re- 
sponds with an error indication. When such an error occurs, an exception report 
may be generated, and the user may be asked to re-enter the requested informa- 
tion. The number of retry attempts may be limited, if desired, for security pur- 
poses. 

[0086] Fig. 4b depicts a payment data transfer operation. Such an op- 
eration is performed, for example, when transaction data is to be collected from 

Case 5393 - 29 - 

16319/05393/DOCS/1127126.3 



client 104 with respect to a subject company. For example, when a user enters a 
transaction into an accounting software package, relevant transaction data may 
be transferred to server 101. Alternatively, such information may be stored lo- 
cally at client 104, and transferred to server 101 in a "batch" operation at periodic 
intervals. 

[0087] Client 104 transmits payment data 411. In one embodiment, 
payment data describes one or more individual transactions with respect to a 
subject company. Transmission 411 may include, for example, a subject com- 
pany identifier, the amount of the transaction, the terms, and the actual days to 
pay for the transaction. Other information may also be transmitted, as appropri- 
ate for the particular embodiment. 

[0088] In an alternative embodiment, payment data is transmitted in 
an aggregated form, so as to combine information from a number of transactions. 
Transmission 411 may then include, for example, a subject company identifier, 
an average days to pay for the subject company, and the number of payments 
received from the subject company. One skilled in the art will recognize that 
other types of aggregated data may be provided in addition to or instead of the 
above-described items. 

[0089] Server 101 transmits a payment data response 412 acknowledg- 
ing receipt of transmission 411. Response 412 indicates "success" or "error" for 
the receipt of transmission 411. In the case of an error, client 104 may retransmit 
the information. An error log may also be generated to track such errors. 
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[0090] Fig. 4c depicts a user subscription operation. Such an operation 
is performed, for example, to handle user requests to subscribe to creditworthi- 
ness reports, or to maintain and/ or modify existing subscriptions. 

[0091] Client 401 transmits a subscription request 421. Request 421 
contains, for example, a description or code specifying the type of service to 
which the client wishes to subscribe. In one embodiment, several different tiers 
of service are available, as described above. Request 421 may also specify the 
particular companies the user is interested in. Request 421 also indicates 
whether the user wishes to subscribe, unsubscribe, or modify an existing sub- 
scription. In addition, request 421 may include billing information, such as a 
credit card, for payment of fees associated with the subscription. Alternatively, 
such billing information may be collected as part of the registration process de- 
scribed above in connection with Fig. 4a. 

[0092] Server 101 transmits a user subscription response 422 acknowl- 
edging receipt of request 421. Response 422 indicates "success" or "error" for the 
receipt of request 421. In the case of an error, client 104 may retransmit the in- 
formation. An error log may also be generated to track such errors. 

[0093] Once a subscription request has been received and acknowl- 
edged, server 101 may transmit reports and/ or alerts at periodic intervals, or 
when creditworthiness information changes for a subject company, or when 
other events occur, according to the specifics of the particular embodiment of the 
invention. 
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[0094] Fig. 4d depicts a credit information transfer operation. Such an 
operation is performed, for example, as part a subscription as established accord- 
ing to the subscription operation described in Fig. 4c. Alternatively, such an op- 
eration is performed in response to a user's " one-off request for credit informa- 
tion on a particular company. Such " one-off' requests may be provided for a set 
fee, or a limited number of such requests may be made available to each user at 
no charge. 

[0095J Server 101 transmits credit information for a subject company 
441 to client 104. Transmission 441 may take any of several forms, including for 
example: 

[0096] - an alert concerning a subject company; 

[0097] - an indication of the rating data for a subject company; and/ or 
[0098] - a creditworthiness report for a subject company. 
[0099] Depending on the type of service to which the user has sub- 
scribed, various alerts, reports, and data may be transmitted, either automatically 
or by user request. 

[001 00] In one embodiment, client 104 transmits a credit information re- 
sponse 442 acknowledging receipt of transmission 441. Response 442 indicates 
"success" or "error" for the receipt of transmission 441. In the case of an error, 
server 101 may retransmit the information. An error log may also be generated 
to track such errors. 
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[01 00] As will be understood by those familiar with the art, the inven- 
tion may be embodied in other specific forms without departing from the spirit 
or essential characteristics thereof. For example, other techniques for collecting 
and aggregating creditworthiness data from clients may be implemented without 
departing from the present invention. Likewise, the particular capitalization or 
naming of the modules, protocols, features, attributes, or any other aspect is not 
mandatory or significant, and the mechanisms that implement the invention or 
its features may have different names or formats. Accordingly, the disclosure of 
the present invention is intended to be illustrative, but not limiting, of the scope 
of the invention, which is set forth in the following claims. 
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